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run -time environment for both run-time and storage use. A 
numeric reference to an object encodes the location of the 
object as an integral oflset from an implicit machine pointer. 
In environments where the size of contiguous virtual 
memory segments is limited, objects are stored in a number 
of fixed-size contiguous chunks in virtual memory called 
pages. A page-offset numeric reference includes an offset 
and a page number, which is used to index a page map that 
contains a page pointer to the beginning of the page. 
Page-oflset numeric references are dereferenced by adding 
the oflset in the numeric reference to the page pointer 
obtained from the page map based on the page number in the 
numeric reference. 
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MACHINE-INDEPENDENT MEMORY 
MANAGEMENT SYSTEM WITHIN A RUN- 
TIME ENVIRONMENT 

RELATED APPLICATIONS 

The present application is related to the following appli- 
cations: 

U.S. patent application Ser. No. 09/248,295, entitled "A 
Memory Management System Within a Run-Time 
Environment/' filed on even date herewith by Harlan 
Sexton et al,, the contents of which are hereby incor- 
porated by reference. 

U.S. patent application Ser. No. 09/248,294, entitled 
"Address Calculation of Invariant References Within a 
Run-Time Environment," filed on even date herewith 
by Harlan Sexton et al., the contents of which are 
hereby incorporated by reference. 

U.S. patent application Ser. No. 09/248,297, entitled "A 
Paged Memory Management System Within a Run- 
Time Environment," filed on even date herewith by 
Harlan Sexton et al., the contents of which are hereby 
incorporated by reference. 

FIELD OF THE INVENTION 

The present invention relates to computer systems and 
more particularly to managing memory for a run-time envi- 
ronment. 

BACKGROUND OF THE INVENTION 

Adynamic run-time environment for a language such as 
JAVA™ is responsible for managing memory for objects 
that are created and destroyed during the execution of a 
program. An object may be defined as a logically contiguous 
atomic unit of typed state of the program. Objects thus 
encapsulate data in particular regions of memory that are 
allocated and deallocated for the program by the dynamic 
run-time environment. 

The state of the program, or "program state," is the set of 
objects, the content of the objects, and the references 
between the objects that exist at a specific point in time 
during the execution of the program. A "reference" to an 
object is an entity used to identify and ultimately access a 
region of memory that stores the data of the object. 
Typically, references between objects in a run-time environ- 
ment are encoded using machine pointers. A machine 
pointer is a native entity that contains the address of the 
object in the main memory, which can be a real address or, 
more commonly, a virtual address. Since machine pointers 
are closely coupled to the underlying hardware and firmware 
of a computer system, machine pointers provide a fast means 
of accessing objects and, hence, are a popular implementa- 
tion for references. 

In a run-time environment, however, a program state that 
contains machine pointers is so machine-dependent that it is 
sometimes disadvantageous. For example, it may be desir- 
able to store the program state on disk or other secondary 
storage medium and restore the stored program state to main 
memory. Some run-time environments, in fact, are designed 
to use the same program state on different types of machines. 
For instance, such run- time environments provide load- 
balancing and crash recovery functions by transferring the 
execution of a program (including its state) from one 
machine to another. 

One of the reasons why machine pointers are not 
machine-independent is that the size in bits of a machine 
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pointer is determined by the extent of the virtual address 
space, which varies between computer architectures. In fact, 
some computer architectures even have pointers of varying 
sizes, for example, near (16-bit) pointers and far (32-bit) 

5 pointers. If program state includes machine pointers whose 
size varies from platform to platform, then the size of objects 
will vary from platform to platform. Furthermore, since the 
size of intervening objects will vary, the relative locations 
between objects will vary from platform to platform. For 

10 example, on a platform with near pointer the relative loca- 
tion of one object can be 48 bytes from another object, but 
on a platform with far pointers, the relative location might 
increase to 96 bytes. 
One approach directed to machine independence, known 

15 as "pointer swizzling," employs two completely different 
formats for representing references: a machine -dependent 
runtime format using pointers for references in main 
memory, and a platform invariant format for encoding 
references in secondary storage. When the reference is 

20 written to secondary storage, machine pointers are converted 
into a machine-independent symbol such as a string or serial 
number. When the reference is read back into main memory 
from secondary storage, the symbol is unswizzled and 
converted back into a machine pointer. Swizzling is also 

25 referred to as "serialization" and "pickling." Since the size 
and relative locations of objects differs between platforms, 
swizzling and unswizzling operations employ a look-up 
technique into an associative data structure, wherein a 
machine pointer is associated with a corresponding symbol. 

30 Look-up operations, however, are computationally 
expensive, requiring many memory accesses into an auxil- 
iary symbol table, typically implemented by a hash table or 
binary tree stored in memory. Thus, frequent storage and 
retrieval of program state into and out of secondary storage 

35 can be responsible for a significant drain on system perfor- 
mance. 

Differences between server environments make machine 
independence very difficult to achieve for portable run-time 
environments even with pointer swizzling. For example, 

40 some operating systems, in practice if not by design, limit 
the guaranteed size of contiguous virtual memory to a 
"page," typically about two or four kilobytes in size. This 
page-size limitation is particularly common for allocating 
objects in shared memory for access by different processes. 

45 Consequently, in paged memory systems, large objects such 
as arrays cannot be contiguously allocated for these servers. 
Prior paged memory systems either failed when sufficiently 
large blocks of virtual memory were not available, or 
employed ad hoc constructions to simulate specific array 

50 types. 

Failure to allocate memory for large objects, merely 
because sufficient contiguous virtual address space is 
unavailable, limits the availability and marketability for 

55 such run -time environments. Ad hoc simulations, moreover, 
are impracticable for paged memory servers especially for 
large, user defined objects, because they are unknown to the 
designer of the run-time environment. Furthermore, it is 
difficult to integrate such ad hoc solutions with the pointer 

6Q swizzling operations for addressing machine independence. 

SUMMARY OF THE INVENTION 

There exists a need for a memory management system 
that can efficiently save and restore program state in a 
65 machine -independent format. Specifically, a need exists for 
a reference format that can be easily stored and has com- 
paratively efficient run-time performance. There is also a 
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need for a memory management system that is portable to, panying drawings and in which like reference numerals refer 

and capable of working with, operating systems that impose to similar elements and in which: 

a page-size limitation to contiguous memory. FIG. 1 depicts a computer system that can be used to 

These and other needs are addressed by the present implement the present invention; 

invention, in which a genus of machine-independent 5 ->/ \- u j * r 1 * c L «• 

formats, called a numeric reference format, is defined for FIG. 2(a) is schematic drawing of a layout of a base-offset 

both run-time and storage. A numeric reference to an object numeric reference. 

encodes the location of the object as an integral offset from FIG. 2(b) is a schematic drawing of a portion of a virtual 

an implicit machine pointer Since the semantics of an memory configuration in which the base-offset numeric 

integer, as opposed to a native machine pointer, can be 1Q reference is used. 

completely specified in terms of size and byte-order, integers FIG. 2(c) is a flowchart for generating a base-offset 

can be easily translated between machines without applying numeric reference from a machine pointer, 

computationally expensive pointer swizzling operations. * . n , 4 r , c . , n . , 

A r .. . j- . • . FIG. 2(a) is a flowchart for dereferencing a base-oflset 

Accordingly, one aspect of the invention relates to a numer i c reference 
computer-implemented method and a computer-readable 

medium bearing instructions for managing memory for a 15 FIG. 3(a) is schematic drawing of a layout of a page-offset 

run-time environment. The methodology includes storing a numeric reference. 

plurality of objects in a virtual memory; storing references FIG. 3(6) is a schematic drawing of a portion of a virtual 

between the objects as numeric references in the virtual memory configuration in which the page-offset numeric 

memory; and storing the objects in a secondary storage that reference is used. 

is not part of the virtual memory and the references in a a> nG 3(c) ^ a flowchart for g^e^g a pa geK>ffset 

numeric reference format in a secondary storage that is not mmeric refcrence from a machine ^ b 

part of the virtual memory. r 

Another aspect of the invention involves a computer- FIG ; 3 ^ is a flowchart for dereferencing a page-offset 

implemented method and a computer-readable medium numeric reference. 

bearing instructions for managing memory for a run-time 25 FIG. 4(a) is schematic drawing of a layout of a self- 
environment. Management of the run-time environment relative numeric reference. 

involves loading objects into virtual memory from second- FIG. 4(b) is a schematic drawing of a portion of a virtual 

ary storage that is not part of the virtual memory; loading memory configuration in which the self-relative numeric 

references between the objects as numeric references into reference is used. 

the virtual memory; and dereferencing one of the numeric 30 FIG ^ ^ a floW chart for generating a self-relative 

references by adding, to a machine pointer, an onset con- numeric refercnce from a machine pointer. 

tained within the numeric reference. Use of numeric refer- . /JV . „ , . , c . . 4 . 

c c , , . ■ . FIG. Aid) is a flowchart for dereferencing a self -relative 

ences for storing references between objects provides an . v / & 

. 4 * * c .u if ur numeric reference, 

invariant representation for references, thereby enabling . 

machine-independent program state to be stored within and 35 FIG. 5 is flowchart for saving and loading numeric 

loaded from secondary storage that is not part of the virtual references in a secondary storage. 

memorv - DESCRIPTION OF THE PREFERRED 

In circumstances where program state containing the EMBODIMENT 
objects and references is to be used in environments where 

the size of contiguous virtual memory segments is limited, ™ A method and apparatus for memory management in a 

the objects are stored or loaded into virtual memory in a run-time environment is described. In the following 

number of fixed-size contiguous chunks called "pages." A description, for the purposes of explanation, numerous spe- 

"page-offset" numeric reference for such environments ^ details are set forth in order to provide a thorough 

includes a page number, which is used to index a page map understanding of the present invention. It will be apparent, 

that contains a page pointer to the beginning of the page, and 45 however, to one skilled in the art that the present invention 

an offset. Page-ofiset numeric references are dereferenced ma y be practiced without these specific details. In other 

by adding the offset in the numeric reference to the page instances, well-known structures and devices are shown in 

pointer obtained from the page map based on the page block diagram form in order to avoid unnecessarily obscur- 

number in the numeric reference. Use of page-offset numeric m S tDe present mvention. 

references allows for a software virtual memory system to 50 Hardware Overview 
be systematically implemented for all system-defined and 

user-defined types supported in a run-time environment, in FIG. 1 is a block diagram that illustrates a computer 

effect, implementing a software paged memory system. system 100 upon which an embodiment of the invention 

Still other objects and advantages of the present invention ma y implemented. Computer system 100 includes a bus 

will become readily apparent from the following detailed 55 102 or other communication mechanism for communicating 

description, simply by way of illustration of the best mode information, and processors 104 and 105 both coupled with 

contemplated of carrying out the invention. As will be bus 102 for processing information. Computer system 100 

realized, the invention is capable of other and different also includes a main memory 106, such as a random access 

embodiments, and its several details are capable of modifi- memory (RAM) or other dynamic storage device, coupled to 

cations in various obvious respects, all without departing 60 bus 102 for storing information and instructions to be 

from the invention. Accordingly, the drawing and descrip- executed by processor 104. Main memory 106 also may be 

tion are to be regarded as illustrative in nature, and not as used for storing temporary variables or other intermediate 

restrictive information during execution of instructions to be executed 

by processor 104 and processor 105. Computer system 100 

BRIEF DESCRIPTION OF THE DRAWINGS 65 further a read onIy mem ory (ROM) 108 or other 

The present invention is illustrated by way of example, static storage device coupled to bus 102 for storing static 

and not by way of limitation, in the figures of the accom- information and instructions for processor 104 and processor 
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105. A storage device 110, such as a magnetic disk or optical to convert the data to an infrared signal. An infrared detector 

disk, is provided and coupled to bus 102 for storing infer- coupled to bus 102 can receive the data carried in the 

mation and instructions. infrared signal and place the data on bus 102. Bus 102 

Computer system 100 may be coupled via bus 102 to a carries the data to main memory 106, from which processor 

display 112, such as a cathode ray tube (CRT), for displaying 5 104 and/or processor 105 retrieves and executes the instruc- 

information to a computer user. An input device 114, includ- t j ons . Th e instructions received by main memory 106 may 

ing alphanumeric and other keys, is coupled to bus 102 for optionally be stored on storage device 1 10 either before or 

communicating information and command selections to after execution by processor 104 and/or processor 105. 

processor 104. Another type of user input device is cursor _ . . . , , . . 

4li1 , , , „ j ■ . • Computer system 100 also includes a communication 

control 116, such as a mouse, a trackball, or cursor direction m ■ . r Ho ij.l • • * c 

, r . . f ' • * 10 interface 118 coupled to bus 102. Communication interface 

keys for communicating direction information and com- v . ,. 

j 1 . -I t\A j c * it 118 provides a two-way data communication coupling to a 

mand selections to processor 104 and for controlling cursor 4 r . .. . iL A f . 4 . . * .1-1^ 

j- 1 n-» -r^' • . -1 • * • 11 u network link 120 that is connected to a local network 122. 

movement on display 112. This input device typically has . c 

_ . rr j • * c . - / \ a For example, communication interlace 118 may be an inte- 

two degrees of freedom in two axes, a first axis (e.g., x) and t , r . ,. . , . /to ~ vn , 3 , 

* . / \ *u * 11 a. j ■ « - c grated services digital network (ISDN) card or a modem to 

a second axis (e.g., y), that allows the device to specify 1( - & . . , & . v ' , 

, 0 J/ r J 15 provide a data communication connection to a correspond- 

positions in a plane. f - . , .. A , . r 

r _ . . r . . mg type of telephone line. As another example, commum- 

Hie invention is related to the use of computer system 100 ca , ion interf ace U8 may be a local ^ network ^ 

for memory management in a ruQ-t.me environment. t0 ovide , data communication connection t0 a compatible 

According to one embodiment of the invention, managing ^ wirdcss , inks ma also bc implcraentcd . In any such 

memory in a run-time environment is provided by computer 20 ^1^,^, communication interface 118 sends and 

system 100 in response to processor 104 and/or processor receives electromagnetic or optical signals that 

105 executing one or more sequences of one or more di ila , da(a strMms representing various types o£ 

instructions contained in main memory 106. Such instruc- information 

tions may be read into main memory 106 from another w . . , , • 

computer-readable medium, such as storage device 110. 25 Network link 120 typ.cally provides data communication 

Execution of the sequences of instructions contained in main lhtm & one or ra ° r f. f^ff 5 10 0,her d , ata devices ' For 

memory 106 causes processor 104 and/or processor 105 to « x « m P« e ; ne , lwork 120 7 lay pr0V,de a connec ,on 

perform the process steps described herein. Although FIG. 1 throu 8 h local nelw °* 122 10 a host computer 124 or to data 

j • . _j i . „ „ + ... ° A 1ft i equipment operated by an Internet Service Provider (ISP) 

depicts a dual processing arrangement with processors 104 w«« • • 

j 1 t\m . . 126. ISP 126 in turn provides data communication services 
and 105, one or more processors in a uni-processing or 30 . , , , , ./ , ; , 
multi-processing arrangement, respectively, may also be through the worldwide packet data communication network 
employed to execute the sequences of instructions contained now commonly referred to as the Internet 128 Locil 
in main memory 106. In alternative embodiments, hard- network 122 and I 1 nterne, 1 12 * both "^ electrical, electro- 
wired circuitry may be used in place of or in combination ma 6 netic ° r °P tlcal s 'S nals . that Cafry , dlg,tal da,a . strcams - 
Ci • . . ■ i * *u • t-u The signals through the various networks and the signals on 
with software instructions to implement the invention. Thus, 35 ^fV. , , . . • ■ * _r no 
embodiments of the invention are not limited to any specific ne ' w ° rk hnk 120 and communication interface 118, 
combination of hardware circuitry and software. ^ch the , dl S» f tal data t0 and frora computer system 
„ j i_i j- »» JL - 100, are exemplary forms of carrier waves transporting the 

The term "computer-readable medium as used herein information 
refers to any medium that participates in providing instruc- 
tions to processor 104 and/or processor 105 for execution. 40 Com P uter svslem 100 can messages and receive 
Such a medium may take many forms, including but not data > including program code, through the network(s), net- 
limited to, non-volatile media, volatile media, and transmis- work hnk 120 > and communication interface 118. In the 
sion media. Non-volatile media include, for example, optical Internet exam P le > a «™ 130 mi S ht **asmil a requested 
or magnetic disks, such as storage device 110. Volatile media c ^ e for an application program through Internet 128 ISP 
include dynamic memory, such as main memory 106. Trans- 45 126 > local ^twork 122 and communication interface 118. In 
mission media include coaxial cables, copper wire and fiber accordance with the invention, one such downloaded appli- 
optics, including the wires that comprise bus 102. Trans- catlon Provides for memory management in a run-time 
mission media can also take the form of acoustic or light environment as described herein. The received code may be 
waves, such as those generated during radio frequency (RF) executed by processor 104 as it is received, and/or stored in 
and infrared (IR) data communications. Common forms of 50 stora S e device 110 ' or other n°n- volatlle storage for later 
computer-readable media include, for example, a floppy execution. In this manner, computer system 100 may obtain 
disk, a flexible disk, hard disk, magnetic tape, any other application code in the form of a carrier wave, 
magnetic medium, a CD-ROM, DVD, any other optical "Virtual memory" refers to memory addressable by a 
medium, punch cards, paper tape, any other physical storage allocation technique in which auxiliary storage, such 
medium with patterns of holes, a RAM, a PROM, and 55 as memory in storage device 110, can be addressed as 
EPROM, a FLASH-EPROM, any other memory chip or though it were part of the main memory 106. More 
cartridge, a carrier wave as described infra, or any other specifically, combinations of hardware, firmware, and oper- 
medium from which a computer can read. ating system cooperate to automatically swap portions of the 

Various forms of computer readable media may bc code and data for an executing process on an as-needed 

involved in carrying one or more sequences of one or more 60 basis - ^ us y the virtual address space may be regarded as 

instructions to processor 104 and/or processor 105 for addressable main memory to a process executing on a 

execution. For example, the instructions may initially be computer system that maps virtual addresses into real 

borne on a magnetic disk of a remote computer. The remote addresses. The size of the virtual address space is usually 

computer can load the instructions into its dynamic memory limited by the size of a native machine pointer, but not by the 

and send the instructions over a telephone line using a 65 actual number of storage elements in main memory 110. 

modem. A modem local to computer system 100 can receive On many operating systems, a process will utilize a 

the data on the telephone line and use an infrared transmitter certain amount of virtual memory that no other user process 
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may access in order to provide data security. "Shared offset can be expressed as a consistent number of bytes from 

memory" refers to the virtual address space on the computer a virtual address. Thus, numeric references include an offset 

system 100 that is concurrently accessible to a plurality of portion that indicates a number of bytes from an implicit 

executing user processes on a processor 104. In some address. Consequently, numeric references are machine - 

embodiments, shared memory is also accessible to executing 5 independent, and program state with numeric references can 

user processes on a plurality of processors, such as proces- be used on incompatible processors, such as processors with 

sors 104 and 105. differently sized machine pointers. 

"Secondary storage" as used herein refers to storage Since a process may use some of its virtual address space 

elements, other than virtual memory, accessible to a process. for storing non-invariant data, i.e. for purposes other than 

Secondary storage may be local or networked. Local sec- 10 storing program state, it is useful to define a physical or 

ondary storage, furnished by storage device 100 on com- logical area of the virtual address space in which the offsets 

puter system 100, typically takes the form of a random between objects remain consistent and thus can be advan- 

access storage device such as a magnetic or optical disk. tageously expressed as numbers. An "object memory" is a 

Networked secondary storage is provided by storage devices subset of the virtual address space containing either existing 

on other computer systems, for example on host 124, 35 objects or available space for allocating new objects. Since 

accessible over a local area network 122, or server 130, an object memory is a subset of the virtual address space, 

accessible over a wide area network such as the Internet. numeric references within the object memory can be smaller 

than machine pointers. For example, 32-bit (four-byte) 

Numeric References numeric references can be profitably used on a computer 

A numeric reference employs a machine-independent 20 with a 64 ' bit virtual address s P ace ( 2<M . about 16 bilUon 
format for encoding references between objects that is gigabytes). Since one of the impediments to machine- 
suitable for both run-time use in virtual memory and storage independence is the differing sizes of machine pointers, the 
use in secondary storage. Unlike symbols and strings use of fixed-size numeric references, even in very large 
employed with pointer swizzling, numeric references are virlual addres * s P ace r s > hel P s ia attainm S a machine- 
easily stored in a secondary storage, in some cases needing 25 independent reference format. 

no conversion at all and in other cases requiring only minor In some implementations, a plurality of object memories 

arithmetic-logical operations such as bit-twiddling and byte is provided, for example, to hold objects of different 

rearrangement. For run-time usage, numeric references can durations, or of other distinct characteristics, to assist in 

be efficiently "dereferenced," that is, converted into a garbage collection. Accordingly, numeric references encode 

machine pointer, without requiring many memory accesses 30 references between, objects in the same object memory, 

into an auxiliary symbol table, hash table, tree, or other References between objects of different object memory, on 

complex data structure. Therefore, numeric references need the other hand, would be encoded in another reference 

not be converted into machines at load time, reducing the format having the same size as the numeric reference. For 

overhead of loading program state. example, indexed references, which are described infra, are 

Preferably, numeric references are implemented in a run- 35 0De of format that ma y be for such inter-object 

time environment that requires all encoded data (e.g. for memory references. 

objects) to be strongly typed and all primitive types, includ- In contrast to symbols swizzled from machine pointers, 

ing references, to have an invariant format. For example, a numeric references are easily converted into and from 

run-time environment may require floating point numbers to 40 machine pointers. In general, a numeric reference to an 

use an IEEE format. In such a run-time environment, object is converted into a machine pointer to the object by 

references between objects, conventionally implemented by adding an offset contained in the numeric reference to an 

machine pointers, are encoded as integer values indicating implicit virtual address. Conversely, a machine pointer to the 

offsets from an implicit machine pointer. The numeric object is converted into a numeric reference by calculating 

reference is defined to be invariant having a specified 45 a pointer difference between the machine pointer to the 

number of bytes, a specified byte-ordering, and a specified object and the implicit virtual address. The implicit virtual 

alignment. The implicit machine pointer is a virtual address address points to the beginning of a region of the virtual 

that is derivable from the memory environment of one the memory space in which the referencing object or the refer- 

objects. enced object is located. The precise identity of the implicit 

For example, numeric references may be encoded as a 50 virtual address de P ends more s P ecificall y 00 lhe s P ecies of 

little endian, two's complement (if signed) four-byte integer the numeric reference that is employed, 

referring to objects aligned on an eight-byte boundary, Three numeric references are disclosed herein: (1) a 

although numeric references in accordance with the present base-offset numeric reference, which contains an offset 

invention, of course, are not limited to these particular relative to a "base address" at the beginning of the object 

specifications. Since almost all machines provide a mapping 55 memory, especially if the object memory consists of a 

between a numeric type and a native primitive type, access- contiguous segment of memory, (2) a page-offset numeric 

ing data in this format is at least as efficient as, for example, reference that is relative to the start of a page also specified 

accessing structures generated by C compilers for that in the numeric reference, and (3) a self-relative numeric 

machine. reference, that is relative to the beginning of the referencing 

The use of numbers to encode references stems from the 60 object, 

realization that the invariant format for encoding objects and Base-Offset Numeric References 
primitive types in a run-time environment ensures that every 

instance of a type will have the same size between platforms. A base -offset numeric reference to an object encodes the 
Since every object has a consistent size between platforms, location of the object as an offset from the beginning of the 
the relative locations between objects are also consistent. 65 object memory within which the object is located. FIG. 2(a) 
Since objects on any platform will be located at a consistent depicts a layout of an exemplary four-byte (32 -bit) base- 
offset from some point in the virtual address space, this offset numeric reference 200. In some embodiments, the 
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base -offset numeric reference 200 includes, in addition to 
the offset, a small number of bits for a tag 202, that is used 
for discriminating among various kinds of numeric and other 
supported reference formats and to cache storage properties 
of the referenced object. The function of the tag 202 is 
described in more detail hereafter. It is to be understood that 
the present invention is not limited to numeric references 
that include a tag 202. 

The base -offset numeric reference 200 includes an offset 
204, which indicates the displacement from a base address. 
If the base-offset numeric reference includes a tag 202, the 
offset 204 may be defined as the numeric reference with the 
tag 202 masked off. For example, a base -offset numeric 
reference having a hexadecimal value of 0x00046740 speci- 
fies a displacement of 0x00046740 or 288,576 bytes from 
the base address. As another example, a three-bit tagged 
numeric reference of 0x00004321 specifies a displacement 
of 0x00004320 or 17,184 bytes from the base address. 

Referencing and dereferencing a base-ofiset numeric ref- 
erence is illustrated with respect to an exemplary memory 
configuration of a portions of a virtual address space 210 as 
shown in FIG. 2(b). Virtual address space 210 includes an 
object memory consisting of a contiguous memory segment 
212 and another object memory consisting of a contiguous 
memory segment 214. The contiguous memory segment size 
is preferably large, for example, in the range of 256 kB (218 
bytes) to 32 MB (225 bytes), such as 4 MB (2 22 bytes). The 
beginning of contiguous memory segment 212 is located at 
a base address marked by base pointer B. Object 216 is 
located at an address marked by object machine pointer P 
within contiguous memory segment 212. 

For purposes of discussion, it will be assumed that the 
object machine pointer is not tagged or if the object machine 
pointer P is tagged, the tag is masked off from the object 
machine pointer P as the beginning of the calculations. In 
those embodiments that employ tagged numeric references, 
it is assumed that the appropriate tag 202 will be handled 
separately in the numeric reference 200. 

FIG. 2(c) illustrates steps taken to produce a base-offset 
numeric reference based on a machine pointer P to object 
216. At step 220, the machine pointer P to object 216 is 
obtained, typically from a variable passed into a function, 
returned from a function or memory allocation operator, 
loaded from a memory address not part of the program state, 
or produced by dereferencing a numeric reference. In a 
working example to illustrate this calculation, a machine 
pointer P having a value of 0x20446740 is obtained from a 
pointer parameter passed into a function of the run-time 
environment. 

At step 222, a base pointer B containing the base address 
of the object memory is determined. If the contiguous 
memory segment is guaranteed to be aligned on a boundary 
at least as large as the size of the contiguous memory 
segment, then the base address can be determined by mask- 
ing off the appropriate number of bits from the machine 
pointer P. In this case, if contiguous memory segment is 
aligned on a 4 MB boundary, then the base pointer can be 
obtained by masking off the least significant 22 bits to 
produce, for example, a base address of 0x2040000. 

On the other hand, for implementations without this 
guarantee, then a header or pre -header for the object may be 
consulted by dereferencing the machine pointer P plus a 
fixed non- negative or negative displacement, respectively. 
In various implementations, the header or pre-header may 
contain the base address itself or an object memory identifier 
that can used to index a data structure to retrieve the base 
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address. In the working example, let us assume that a base 
pointer having a base address of 0x20400000 is determined. 

At step 224, the ofifeet 204 that will be stored in the 
base-offset numeric reference 200 is calculated as a differ- 

5 ence of the virtual address of the object 216 and the base 
address of the object memory consisting of the contiguous 
memory segment 212. This calculation can be performed by 
subtracting the base pointer B from the object pointer P. For 
the implementations that impose a sufficient alignment 

10 restriction on contiguous memory segments, then steps 222 
and 224 can be coalesced into a single masking of all but the 
least 22 significant bits, e.g. OFFSET=P&~(~0«22). In the 
working example, the calculated offset is 0x20446740- 
0x20400000=0x00046740, which constitutes the base-offset 
numeric reference. An appropriate tag 202, if implemented, 

35 is added or logically-ored into the result. 

FIG. 2(d) illustrates steps taken to produce a machine 
pointer P based on a base -offset numeric reference to object 
216. At step 230, the base-offset numeric reference to object 
216 is obtained, typically by reading from a memory address 

20 of the program state. In a working example to illustrate this 
calculation, a base-offset numeric reference having a value 
of 0x00046740 is obtained from reading a program state 
memory location under control of a memory management 
component of the run-time environment. 

25 At step 232, a base pointer B containing the base address 
of the object memory is determined. If the contiguous 
memory segment is guaranteed to be aligned on a boundary 
at least as large as the size of the contiguous memory 
segment, then the base address can be determined by mask- 

30 ing the appropriate number of bits of the virtual address of 
the object that contains the numeric reference, or the "ref- 
erencing object." In this case, if the contiguous memory 
segment is aligned on a 4 MB boundary, then the base 
pointer can be obtained by masking off the least significant 

35 22 bits to produce, for example, a base address of 
0x2040000. 

On the other hand, for implementations without this 
guarantee, a header or pre-header for the referencing object 
may be consulted by dereferencing the machine pointer P 

40 plus a fixed offset. In various implementations, the header or 
pre-header may contain the base address itself or an object 
memory identifier that can used to index a data structure to 
retrieve the base address. In the working example, let us 
assume that a base pointer having a base address of 

45 0x20400000 is determined. 

At step 234, the virtual address of the object 216 is 
obtained by adding the offset 204 stored in the numeric 
reference 200 to the base address of the object memory 
consisting of the contiguous memory segment 212. This 

50 calculation can be performed by adding the offset 204 to the 
base pointer B. An appropriate machine pointer tag 202, if 
necessary, is added or logically-ored into the result. In the 
working example, the virtual address of the object 214 is 
calculated to be 0x20400000+0x00046740=0x20446740. 

55 

Page-Offset Numeric References 

In circumstances where the program state is to be used in 
server environments in which the maximum size of a 
contiguous memory segment is severely constrained, it is 

60 useful to divide the program state into a plurality of fixed- 
size contiguous chunks of memory called "pages." A page is 
a moderately sized contiguous memory segment that is 
supported within the server environments, especially for 
shared memory. The pages of an object memory need not be 

65 contiguous; in other words, a paged object memory contains 
a plurality of contiguous memory segments in multiples of 
the page size. 
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To access the disparate pages of an object memory, a page 
map is maintained for a paged object memory to keep track 
of the pages. Each page is assigned a page number, which is 
used to index the page map to fetch the virtual address of the 
beginning of the page, called a page address. The indirection 
provided by the page map indexed by a page number allows 
pages to be relocated simply by updating the page address in 
the page map. A certain amount of space, called a "page 
header" is reserved at the beginning of the page to store 
useful information for the memory management of the page, 
including the page number, the address of the page map, and 
the base address of the object memory (page address for 
page 0). 

Accordingly, a page-offset numeric reference to an object 
encodes the location of the object as an offset from the 
beginning of the page within which the object is located. 
FIG. 3(a) depicts a layout of an exemplary four-byte (32-bit) 
page -offset numeric reference 300. In some embodiments, 
the page-offset numeric reference 300 includes, in addition 
to the offset, a small number of bits for a tag 302, that is used 
for discriminating among various kinds of numeric and other 
supported reference formats and to cache storage properties 
of the referenced object. The function of the tag 302 is 
described in more detail infra, and it is to be understood, of 
course, that the present invention is not limited to numeric 
references that include a tag 302. 

The page-offset numeric reference 300 includes an offset 
304, which indicates the displacement from a page address. 
The page address is determined by accessing a page map for 
the object memory based on a page number 304 also 
contained in the page -offset numeric reference. If the page- 
offsct numeric reference includes a tag 302 and a page 
number 306, the offset 304 may be defined as the numeric 
reference with the tag 302 and the page number 306 masked 
off. For example, a page-offset numeric reference having a 
hexadecimal value of 0x00001740 specifies a displacement 
of 0x00000740 or 1,856 bytes from the page address of page 
number 1. 

Referencing and dereferencing a page-offset numeric ref- 
erence is illustrated with respect to an exemplary memory 
configuration of a portions of a virtual address space 310 as 
shown in FIG. 3(b). Virtual address space 310 includes an 
object memory comprising pages 312a, 3126, 312c, 312a*, 
and 312e. A page map 314, which in one embodiment is 
stored in page 0 (312a), contains entries for page addresses 
corresponding to the pages 312a, 312b, 312c, 312a*, and 
312e. The page size is preferably moderately sized and 
compatible with those servers which severely restrict the 
size of contiguous memory segments. For example, the page 
size may be in the range of 256B (2 8 bytes) to 32 kB (2 15 
bytes), such as 4 kB (2 12 bytes). The beginning of page 3126 
is located at a page address marked by page pointer PP. 
Object 316 is located at an address marked by object 
machine pointer P within page 3126. 

For purposes of discussion, it will be assumed that the 
object machine pointer is not tagged or if the object machine 
pointer P is tagged, the tag is masked off from the object 
machine pointer P as the beginning of the calculations. In 
those embodiments that employ tagged numeric references, 
then it is assumed that the appropriate tag 302 will be 
handled separately in the numeric reference 300. 

FIG. 3(c) illustrates steps taken to produce a page -offset 
numeric reference based on a machine pointer P to object 
316. At step 320, the machine pointer P to object 316 is 
obtained, typically from a variable passed into a function, 
returned from a function or memory allocation operator, 
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loaded from a memory address not part of the program state, 
or produced by dereferencing a numeric reference. In a 
working example to illustrate this calculation, a machine 
pointer P having a value of 0x20446740 is obtained from a 
5 pointer parameter passed into a function of the run-time 
environment. 

At step 322, a page pointer PP containing the page address 
of the page is determined. If the page is guaranteed to be 
aligned on a boundary at least as large as the fixed-size of the 
30 page, then the page address can be determined by masking 
off the appropriate number of bits from the machine pointer 
P. In this case, if page is aligned on a 4 kB boundary, then 
the base pointer can be obtained by masking off the least 
significant 12 bits to produce, for example, a page address of 
15 0x20446000. 

On the other hand, for implementations without this page 
alignment guarantee, a header or pre -header for the object 
may be consulted by dereferencing the machine pointer P 
plus a fixed non-negative or negative displacement, respec- 
tively. In various implementations, the header or pre-header 
may contain the page address itself or an offset from the 
referencing object to the beginning of the page. In the 
working example, let us assume that a page pointer having 
a page address of 0x20446000 is determined. 

At step 324, the page number 306 and the offset 304 
portions of the page -offset numeric reference are deter- 
mined. The page address is used to fetch the corresponding 
page number from the page header of page 3126. Preferably, 
this page number is already shifted by the page size to 
facilitate the bitwise masking operations. In the example, if 
the object is in 4 kB page 1 (i.e. page 3126), then the page 
number would be 1«1 2-0x00001000. The offset 304 is 
calculated as a difference of the virtual address of the object 
35 316 and the page address of the page 3126. This calculation 
can be performed by subtracting the page pointer PP from 
the object pointer P. In the working example, the calculated 
offset 304 is 0x20446740-0x20446000-0x00000740. Com- 
bining the shifted page number and the offset produces a 
40 page-offset numeric reference of 0x0000 1 000|0x00000740« 
0x00001740. An appropriate tag 302, if implemented, is 
added or logically-ored into the result. 

FIG. 3(d) illustrates steps taken to produce a machine 
pointer P based on a page-offset numeric reference to object 
45 316. At step 330, the page-offset numeric reference to object 
316 is obtained, typically by reading from a memory 
address. In a working example to illustrate this calculation, 
a page-offset numeric reference having a value of 
0x00001740 is obtained from reading a program state 
50 memory location under control of a memory management 
component of the run-time environment. 

At step 332, the page pointer PP containing the page 
address of the page is determined. First, the appropriate page 
map 314 needs to be identified, which is found in the page 
55 header of the referencing object. If the page of the refer- 
encing object is guaranteed to be aligned on a boundary at 
least as large as the size of the page, then the referencing 
page address can be determined by masking the appropriate 
number of bits of the virtual address of the referencing 
60 object. In this case, if the page is aligned on a 4 kB boundary, 
then the referencing page address pointer can be obtained by 
masking off the least significant 12 bits of 0xlC209B70, for 
example, to produce a page address of OxlC209000. 
On the other hand, for implementations without this 
65 guarantee, a header or pre-header for the referencing object 
may be consulted by dereferencing the machine pointer P 
plus a fixed offset. In various implementations, the header or 
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pre -header may contain the referencing page address itself object contains a self- relative numeric reference to a refer- 

or an offset from the referencing object to the beginning of enced object, the self- relative numeric reference contains an 

the referencing page. offset to the referenced object that is relative to an address 

Accordingly, the page map 314 is reachable by a field of the referencing object, e.g. the starting address of the 

reserved in the referencing page header. The appropriate 5 object. Dereferencing a self- relative numeric reference 

entry in page map 314 is determined by indexing the page therefore entails adding the offset to the virtual address the 

306 value, shifted right by an appropriate amount, e.g. 12 for start of the referencing object. Since the virtual address to 

4 kB pages. In the working example, assume that a page the referencing object is used to fetch the self-relative 

pointer having a page address of 0x20446000 is thus fetched numeric reference from memory in the first place, a machine 

from entry #1 of page map 314. i° pointer with this virtual address is probably sitting in a 

At step 334, the virtual address of the object 316 is high-speed register. Even if the machine pointer is not in a 

obtained by adding the offset 304 stored in the numeric register, it is on the stack and probably in the cache or in a 

reference 300 to the page address of the page 312b, fetched loaded P a S e - Therefore, the overhead for dereferencing a 

from page map 314. This calculation can be performed by self-relative numeric reference is commensurate with deref- 

adding or logically oring the offset 304 to the page pointer 15 f rencing a machine pointer and much less than dereferenc- 

PP. In the working example, the virtual address of the object in S a page-offset pointer. 

314 is calculated to be 0x20446000+0x00000740- Accordingly, a self- relative numeric reference to an object 

0x20446740. An appropriate machine pointer tag 302, if encodes the location of the object as an offset from the 

necessary, is added or logically-ored into the result. beginning of the referencing object. FIG. 4(a) depicts a 

Since a paged object crosses a page boundary, slot-access 20 lavout of an exemplary four-byte (32-bit) self-relative 

operations for the paged object need additional support from numeric reference 400. In some embodiments, the self- 

the run-time environment. A slot-access operation gets or relative numeric reference 400 includes, in addition to the 

sets a value of a "slot" in a object (i.e. a field or instance offset > a sma11 number of bits for a tag 402, that is used for 

variable) at a known displacement from the virtual address discriminating among various kinds of numeric and other 

of the beginning of the object. If the object is contiguous, 25 supported reference formats and to cache storage properties 

then the address of the slot can be determined simply by of tne referenced object. The function of the tag 402 is 

adding the displacement to the beginning of the object. For described in more detail infra, and it is to be understood, of 

paged objects, on the other hand, this addition results in an course, that the present invention is not limited to numeric 

invalid address, because the page boundary may occur references that include a tag 402. 

between any of the slots and vary from instance to instance. 30 The self -relative numeric reference 400 includes an offset 

Accordingly, a slot-access operation of a machine pointer 404 > wnicn indicates the displacement from the referencing 

to a paged object requires first converting the machine object. If the self-relative numeric reference includes a tag 

pointer in to a page-offset numeric reference and checking to 402, the offset 404 may be defined as the numeric reference 

see if adding the displacement crosses one or more page ^e tag 402 masked off. For example, a self-relative 

boundaries. The displacement is added to the page-offset numeric reference having a hexadecimal value of 

numeric reference and adjusted to account for the size of the 0x0423CBD0 specifies a displacement of 69,454,800 bytes 

page headers for each of the crossed boundaries. The result- from the referencing object. As another example, a three-bit 

ant page-offset numeric reference is then dereferenced as * a gged numeric reference of 0x00004321 specifies a dis- 

described supra. placement of 0x00004320 or 17,184 bytes from the refer- 

It is evident that the slot-access operation for a paged encing object, 

object is fairly cumbersome. Theref ore, it is desirable, when Referencing and dereferencing a self-relative numeric 

allocating memory for an object, to find or allocate a new reference is illustrated with respect to an exemplary memory 

page that can fit the object if possible. Preferably, only those configuration of portions of a virtual address space 410 as 

objects that are larger than the effective page size (i.e. the 45 shown in FIG. 4(b). Virtual address space 410 includes an 

fixed pages size minus the page header size) are allocated on object memory comprising page 412a and 4126. Object 414 

a plurality of pages. Since distinguishing between paged is located at an address within page 412a marked by 

objects and contiguous objects is a common operation in machine pointer S, and object 216 is located at an address 

performing a slot-access operation, the contiguity of the within page 412b marked by object machine pointer P. 

referenced object is preferably stored in a machine pointer 50 For purposes of discussion, it will be assumed that, if the 

tag as a storage property to avoid dereferencing the machine object machine pointer P is tagged, then the tag is masked off 

pointer to fetch that storage property from the object's from the object machine pointer P as the beginning of the 

header. calculations. In those embodiments that employ tagged 

numeric references, then it is assumed that the appropriate 

Self-Relative Numeric References s5 tag 402 win be Mt in the numeric re f e rence 400. In another 

As described supra, dereferencing a page-offset numeric embodiment, wherein machine pointers and numeric refer- 

reference to a object, whether the object is paged or enecs arc both tagged, a tag assignment scheme may be 

contiguous, involves some overhead, which incurs a perfor- adopted such that the calculations for referencing and deref- 

mance penalty that may be unacceptable for some imple- erencing disclosed herein also generate the appropriate tag, 

mentation environments. More specifically, dereferencing a 60 without having to handle the tags separately, 

page-offset numeric reference requires at least one memory FIG. 4(c) illustrates steps taken to produce a self-relative 

access to the page map, which may not be currently in cache numeric reference based on a machine pointer P to object 

or, worse, loaded in volatile memory. Consequently, resolv- 416 for storage in object 414. At step 420, the machine 

ing the resulting cache miss or page fault requires additional pointer P to object 416 is obtained, typically from a variable 

machine cycles and therefore imposes a performance hit. passed into a function, returned from a function or memory 

Because of the performance hit, it is desirable to define allocation operator, loaded from a memory address not part 

and use self-relative numeric references. When a referencing of the program state, or produced by dereferencing a 
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numeric reference. In a working example to illustrate this 
calculation, a machine pointer P having a value of 
0x20446740 is obtained from a pointer parameter passed 
into a function of the run-time environment. 

At step 422, a source machine pointer S containing the 5 
virtual address of the referencing object determined. Since 
the self- relative numeric reference is to be stored in the 
referencing object, this pointer is already available, typically 
in a high-speed memory such as a register or cache. In the 
working example, let us assume that a source pointer S 10 
having a base address of 0xlC209B70 is determined. 

At step 424, the ofTset 404 that will be stored in the 
self-relative numeric reference 400 is calculated as a differ- 
ence of the virtual address of the referenced object 616 and 
the virtual address of the referencing object 414. This 15 
calculation can be performed by subtracting the source 
pointer S from the object pointer P. In the working example, 
the calculated offset is 0x20446740-0x1 C209B70- 
OxO423CBD0, which constitutes the self -relative numeric 
reference. When the calculated offset is negative, software 
arithmetic may be employed to ensure that the negative 
number is in the proper format for a portable numeric 
reference. For example, such software arithmetic would 
employed in an embodiment wherein negative numeric 
references are required to be in two's complement repre- 
sentation but the underlying hardware employs a different 
representation for negative number, for example one's 
complement or sign-magnitude. Finally, an appropriate tag 
402, if implemented, is added or logically-ored into the 
result. 

FIG. 4(d) illustrates steps taken to produce a machine 
pointer P based on a self-relative numeric reference to object 
416. At step 430, the self-relative numeric reference to 
object 416 is obtained, typically by reading from a memory 
address of the program state, such as from within referenc- 
ing object 414. When the offset in the numeric reference is 
a negative number, software arithmetic may be employed to 
ensure that the negative number is in the proper format for 
the underlying hardware. In a working example to illustrate 
this calculation, a self-relative numeric reference having a 
value of 0x0423CBD0 is obtained from reading a program 
state memory location under control of a memory manage- 
ment component of the run-time environment. 

At step 432, a source pointer S containing the virtual 
address of the referencing object, Since the self-relative 
numeric reference is fetched from the referencing object, the 
machine pointer for the referencing object 414 is already 
available, typically in a high-speed memory such as a 
register or cache. In the working example, let us assume that 50 
a source pointer S having a virtual address of OxlC209B70 
is determined. 

At step 434, the virtual address of the object 416 is 
obtained by adding the offset 404 stored in the numeric 
reference 400 to the source address of the referencing object 55 
414, This calculation can be performed by adding the offset 
404 to the source pointer S. An appropriate machine pointer 
tag 402, if necessary, is added or logically-ored into the 
result. In the working example, the virtual address of the 
object 414 is calculated to be OxlC209B70+0x0423CBD0« eo 
0x20446740. 

Saving and Loading Program State 

FIG. 5 is a flowchart illustrating a life cycle of numeric 
references within a runtime environment. At step 500, the 65 
run-lime environment instantiates an object, by allocating 
and initializing memory for the object. The run-time envi- 
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ronment manipulates access and updates to the object 
through a machine pointer. 

When a reference to the object is to be stored in another 
object, the "referencing object," the machine pointer is 
converted into a numeric reference (step 502). This opera- 
tion involves calculating an offset (preferably measured in 
bytes) from the object to an implied pointer to a predefined 
location in an area of virtual memory associated with either 
the referencing object or the referenced object, depending on 
the kind of numeric reference employed. For example, a 
base-offset numeric reference specifies an offset from the 
beginning of an object memory; a page-offset numeric 
reference specifies an offset from the beginning of a page; 
and a self-relative numeric reference specifies an offset from 
the beginning of the referencing object. In other 
embodiments, the numeric reference may be relative to the 
end of the memory area, or to a location at a fixed displace- 
ment from the beginning or end of the memory area, whether 
interior or exterior. 

At step 504, objects are accessed during run-time by 
dereferencing the numeric references. Dereferencing a 
numeric reference involving generating the implied machine 
pointer and adding the offset in the numeric reference. Of the 
three described kinds of numeric references, self-relative 
numeric references exhibit the best performance, because 
the implied pointer, the beginning of the referencing object, 
is almost always already available. Page-offset numeric 
references, on the other hand, exhibit the worst run-time 
performance because it is necessary to access the page map. 

When the program state is to be saved to a secondary 
storage medium, both the objects (step 506) and the numeric 
references contained in the objects (step 508) are saved. 
Since numeric references provide an invariant, machine- 
independent representation, numeric references saved to 
secondary storage will take up the same space as in virtual 
memory. To the extent that any processing or software 
arithmetic needs to occur for saving and loading numerical 
references, e.g. to handle endianness or one's complement 
architectures, this processing will not require changes to the 
size of the numeric references. Therefore, objects (step 510) 
and numeric references (step 512) can be loaded later in the 
process or by another processed with little overhead, and 
then accessed as any other numeric reference (step 504). 

Each of the three described kinds of numeric references 
exhibit different degrees of flexibility in saving and loading 
to and from secondary storage. Page-offset numeric refer- 
ences are the most flexible because the pages can be relo- 
cated anywhere in the virtual memory as long as the page 
map is updated. Base-offset numeric references, however, 
are limited to systems capable of allocating contiguous 
segments of the virtual memory that are as large as the object 
memory. Self-relative numeric references, although imple- 
ment able on a paged memory system, require that the 
various pages be loaded in the same relative locations, which 
may not always be possible. 

Accordingly, there is a trade-off between run-time per- 
formance and flexibility in secondary storage. Of the three 
types of numeric references described supra, self -relative 
numeric references exhibit the best run-time performance 
and page-offset numeric references exhibit the most flexible 
secondary storage properties. Therefore, it would be desir- 
able to use self-relative numeric references for run-time 
usage and page-offset numeric references for secondary 
storage usage. 

In accordance with one embodiment, numeric references 
are converted into page -offset numeric reference when sav- 
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ing to the secondary storage (step 508). Furthermore, run- numeric reference contains the offset for the numeric refer- 

time numeric references, where possible, are implemented ence and other information important for the particular 

as self -relative numeric references. More specifics Qy, a format of the numeric reference, such as the page number, 

numeric reference is instantiated in step 502 as a self- Reference tagging also allows numeric references to be 

relative numeric reference and a page-offset numeric refer- 5 used in conjunction with other reference types. For example, 

ence loaded from secondary storage in step 512 is converted an indexed reference is a type of reference that evaluates to 

into a self-relative numeric reference. This conversion can an array entry of one sort of another. Some the non-tag bits 

be eager, at load time, or lazy, at dereference time. Unlike of the indexed reference specify the array and others specific 

pointer swizzling, the overhead for convert between numeric a n index into the array. Apage-offset numeric reference may 

reference types is relatively low, does not violate the invari- 10 be thought of a hybrid numeric reference and indexed 

ant format of objects, and be deferred until necessary. reference, wherein the page number specifies an index into 

the page map and the offset portion specifies a relative 

Tagged Numeric References location of the object within the page. As mentioned earlier, 

In some environments, it is necessary for page-offset some embodiments restrict the use of numeric references for 

numeric references and self-references to co-exist during 35 encoding references between objects in the same object 

run-time. For example, a self-relative numeric reference memory; accordingly, indexed references provide a mecha- 

might be limited to 32 bits and therefore cannot express a msm for supporting references between objects of different 

reference between objects that are displaced from each other object memories. 

by more than 2 32 bytes (four gigabytes), which can easily Numeric references therefore encode references between 

happen on a 64-bit virtual memory system. Consequently, 20 objects an invariant format that is both efficient for run-time 

self-relative numeric references would be used with near usage and flexible for machine-independent secondary stor- 

objects and page -offset numeric references would be used age. Since numeric references encode a reference as an 

with far objects. Since self-relative numeric references and integral offset from an implied machine pointer, numeric 

page -offset numeric references are dereferenced differently references can easily between converted into and from 

and since the performance of dereferencing self-relative 25 machine pointers, without requiring expensive lookups into 

numeric references is critical to the overall performance of associative data structure as in pointer swizzling. Moreover, 

the run-time environment, it is desirable for a cheap way to page-offset numeric references provide a systematic 

distinguish between self-relative numeric references and approach for managing memory for large objects, allowing 

page-offset numeric references. the large objects to be broken up into non-contiguous pages 

According to one embodiment, numeric references are 3 ° ™ a manner transparent to the user code, 

tagged to indicate whether the numeric references are self- While this invention has been described in connection 

relative numeric references or page-offset numeric refer- with whal « presently considered to be the most practical 

ences. In other words, a certain number of bits in a numeric and preferred embodiment, it is to be understood that the 

reference, for example the higher-order bits or lower-order 35 invention is not limited to the disclosed embodiment, but on 

bits, is reserved for distinguishing the numeric reference the contrary, is intended to cover various modifications and 

format. The information embedded within the numeric equivalent arrangements included within the spirit and scope 

reference, which is likely to be sitting in a fast-access of the appended claims, 

machine register, can therefore be retrieved very quickly, What is claimed is: 

without requiring additional memory cycles to fetch the 1 A method of managing memory for a run-time 

header of the referenced object. environment, comprising the computer-implemented steps 

A preferred implementation of numeric reference tagging . . . 

introduces an alignment invariant and then exploits the maintaining a plurality of objects and references between 

alignment invariant in a run-time environment to encode the ^ ob i ects 35 numenc references id a virtual memory 

numeric reference format in the lower-order bits. 45 for run-time use wherein a numeric reference includes 

Specifically, objects managed by the run-time environment aQ mte S er offiiet from a virtual memor y address and lhe 

are stored at an N-bit aligned address, or, in other words, the ob J ects maintained in the virtual memory are instanti- 

storage for these objects begins at virtual addresses at . ated bv a first P rocess executin S on a fif st processor; 

2^-byte boundaries. For example, if the objects can be stored and 

at three-bit aligned addresses, that is, on 2 3 -8 byte 50 storing without swizzling the objects and the references in 

boundaries, a legal start address for such an object might be a numeric reference format in a secondary storage that 

0x20446740, but an address such as 0x20446743 is not a k aot P art of the virtual memory, wherein the objects 

valid start address for the storage of an object. Consequently, stored in the secondary storage are loadable without 

the three least significant bits of the numeric reference do not unswizzling by a second process executing on a second 

serve to differentiate different objects, since only one of the 55 processor that is incompatible with the first processor, 

eight values for the three least significant bits is a legal 2 - The method of claim 1, wherein: 

address and the remaining seven values do not point to any the objects maintained in the virtual memory are instan- 

other object. Given this alignment restriction, numeric ref- tiated on a first virtual memory page; and 

erences that resolve to addresses 0x20446740 through the objects stored in the secondary storage are loadable 

0x20446747 effectively refer to the same object. 60 ml ° a second virtual memory page. 

Therefore, any of the N least significant bits of a reference 3. A method of managing memory for a run-time 

to an N-bit aligned object can be used as a tag to encode environment, comprising the steps of: 

other information, namely the format of the numeric refer- storing a plurality of objects in a virtual memory; 

ence and storage properties of the reference object. For generating numeric references by calculating pointer dif- 

example, tag values of 0 and 4 may indicate a page-offset 65 ferences between addresses of the objects and machine 

numeric reference, while tag values of 3 and 7 indicate a pointers at predetermined locations relative to regions 

self-relative numeric reference. The remaining portion of the of the virtual memory in which the objects are located; 
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storing references between the objects as the numeric 
references in the virtual memory, wherein a numeric 
reference includes an offset from a virtual memory 
address; and 

storing the objects and the references in a numeric refer- 
ence format in a secondary storage that is not part of the 
virtual memory. 

4. The method of claim 3, wherein: 
the step of storing a plurality of objects in a virtual 

memory includes the step of storing the objects within 
a contiguous memory segment; 
the step of storing references between the objects in a 
numeric reference format in the virtual memory 
includes the step of storing the references as base-offset 
numeric references. 

5. The method of claim 4, wherein one of the predeter- 
mined locations indicates a beginning of the contiguous 
memory segment to produce the base-ofiset numeric refer- 
ences. 

6. The method of claim 3, wherein: 
the step of storing a plurality of objects in a virtual 

memory includes the step of storing the objects within 
a plurality of non -contiguous pages; and 
the step of storing references between the objects as 
numeric references in the virtual memory includes the 
step of storing the references as page-offset numeric 
references. 

7. The method of claim 6, wherein one of the predeter- 
mined locations indicates a beginning of a page storing the 
objects to produce the page-offset numeric references. 

8. The method of claim 3, wherein the one of the 
predetermined locations indicates a beginning of referencing 
objects. 

9. The method of claim 3, wherein the step of generating 35 
the numeric references includes assigning a tag value in tag 
portion of a numeric reference, said tag value indicating 
whether the numeric reference is a self-relative reference. 

10. A method of managing memory for a run-time 
environment, comprising the steps of: 

storing a plurality of objects in a virtual memory; 
storing the references between the objects as self-relative 

numeric references in the virtual memory, wherein a 

self-relative numeric reference includes an offset from 

a virtual memory address; and 
storing the references in a page-offset numeric reference 

format in a secondary storage that is not part of the 

virtual memory. 

11. A method of managing memory by a first process 
executing on a first processor in a run-time environment, 
comprising the computer-implemented steps of: 

loading a plurality of objects into a virtual memory from 
a secondary storage that is not part of the virtual 
memory, wherein the objects stored in the secondary 
storage are loadable without unswizzling by a second 
process executing on a second processor that is incom- 
patible with the first processor; 
loading without unswizzling references between the 
objects as numeric references from the secondary stor- $o 
age into the virtual memory for run-time use; and 
dereferencing one of the numeric references by adding, to 
a virtual memory address, an integer offset contained 
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loading a plurality of objects into a contiguous memory 
segment of a virtual memory from a secondary storage 
that is not part of the virtual memory, wherein the 
objects stored in the secondary storage are loadable 
without unswizzling by a second process executing on 
a second processor that is incompatible with the first 
processor; 

loading references between the objects as numeric refer- 
ences from the secondary storage into the virtual 
memory; and 

dereferencing one of the numeric references by adding an 
integer offset contained within the one of the numeric 
references to a machine pointer holding an address of 
a beginning of the contiguous memory segment. 

13. A method of managing memory in a run-time 
environment, comprising the steps of: 

loading a plurality of objects into a plurality of non- 
contiguous pages; 
updating a page map containing a plurality of page 
pointers holding addresses of a beginning of corre- 
sponding said pages; 
loading references between the objects as numeric refer- 
ences from the secondary storage into the virtual 
memory; and 
dereferencing one of the numeric references by: 

fetching a page pointer from the page map based on a 
page number contained within the one of the numeric 
references, and 
adding an offset contained within the one of the 
numeric references to the page pointer. 

14. A method of managing memory in a run-time 
environment, comprising the steps of: 

loading a plurality of objects into a virtual memory from 
a secondary storage that is not part of the virtual 
memory; 

loading references between the objects as numeric refer- 
ences from the secondary storage into the virtual 
memory; converting base-offset numeric references 
into self-relative numeric references; and 

dereferencing one of the numeric references by adding an 
offset contained within the one of the numeric refer- 
ences to a machine pointer holding an address of a 
beginning of an object containing the one of the 
numeric references. 

15. A method of managing memory in a run-time 
environment, comprising the steps of: 

loading a plurality of objects into a virtual memory from 
a secondary storage that is not part of the virtual 
memory; 

loading the references between the objects as page-offset 
numeric references from a secondary storage; 

converting the page-offset numeric references into self- 
relative numeric references; 

storing the self- relative references in the virtual memory; 
and 

dereferencing one of the numeric references by adding, to 
a machine pointer, an offset contained within the one of 
the numeric references. 

16. A computer-readable medium bearing instructions for 
managing memory for a run-time environment, said instruc- 
tions arranged, when executed, for causing one or more 



within the one of the numeric references. 

12. A method of managing memory by a first process 65 processors to perform the steps of: 

executing on a first processor in a run-time environment, maintaining a plurality of objects and references between 

comprising the steps of: the objects as numeric references in a virtual memory 
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for run-time use, wherein a numeric reference includes 
an integer offset from a virtual memory address and the 
objects maintained in the virtual memory are instanti- 
ated by a first process executing on a first processor; 
and 

storing without swizzling the objects and the references in 
a numeric reference format in a secondary storage that 
is not part of the virtual memory, wherein the objects 
stored in the secondary storage are loadable without 
unswizzling by a second process executing on a second 
processor that is incompatible with the first processor. 

17. The computer- readable medium of claim 16, wherein: 
the objects maintained in the virtual memory are instan- 
tiated on a first virtual memory page; and 

the objects stored in the secondary storage are loadable 
into a second virtual memory page. 

18. A computer-readable medium bearing instructions for 
managing memory for a run-time environment, said instruc- 
tions arranged, when executed, to cause one or more pro- 
cessors to perform the steps of: 

storing a plurality of objects in a virtual memory; 

generating numeric references by calculating pointer dif- 
ferences between addresses of the objects and machine 25 
pointers at predetermined locations relative to regions 
of the virtual memory in which the objects are located 

storing references between the objects as the numeric 
references in the virtual memory, wherein a numeric 
reference includes an offset from a virtual memory 
address; and 

storing the objects and the references in a numeric refer- 
ence format in a secondary storage that is not part of the 
virtual memory. 

19. The computer-readable medium of claim 18, wherein: 
the step of storing a plurality of objects in a virtual 

memory includes the step of storing the objects within 
a contiguous memory segment; 4Q 
the step of storing references between the objects in a 
numeric reference format in the virtual memory 
includes the step of storing the references as base-offset 
numeric references. 

20. The computer-readable medium of claim 19, wherein 45 
one of the predetermined locations indicates a beginning of 
the contiguous memory segment to produce the base-offset 
numeric references. 

21. The computer-readable medium of claim 18, wherein: 
the step of storing a plurality of objects in a virtual 

memory includes the step of storing the objects within 
a plurality of non-contiguous pages; and 
the step of storing references between the objects as 
numeric references in the virtual memory includes the 55 
step of storing the references as page-offset numeric 
references, 

22. The computer-readable medium of claim 21, wherein 
one of the predetermined locations indicates a beginning of 
a page storing the objects to produce the page -offset numeric 60 
references. 

23. The computer-readable medium of claim 18, wherein 
one of the predetermined locations indicates a beginning of 
referencing objects. 

24. The computer-readable medium of claim 18, wherein 65 
the step of generating the numeric references includes 
assigning a tag value in tag portion of a numeric reference, 



said tag value indicating whether the numeric reference is a 
self-relative reference. 

25. A computer-readable medium bearing instructions for 
managing memory for a run-time environment, said instruc- 
tions arranged to cause one or more processors to perform 
the steps of: 

storing a plurality of objects in a virtual memory; 
storing the references between the objects as self-relative 
numeric references in the virtual memory, wherein a 
self-relative numeric reference includes an offset from 
a virtual memory address; and 
storing the references in a page-offset numeric reference 
format in a secondary storage that is not part of the 
15 virtual memory. 

26. A computer-readable medium bearing instructions for 
managing memory by a first process executing on a first 
processor in a run-time environment, said instructions 
arranged, when executed, to cause one or more processors to 

20 perform the steps of: 

loading a plurality of objects into a virtual memory from 
a secondary storage that is not part of the virtual 
memory, wherein the objects stored in the secondary 
storage are loadable without unswizzling by a second 
process executing on a second processor that is incom- 
patible with the first processor; 
loading without unswizzling references between the 
objects as numeric references from the secondary stor- 
age into the virtual memory for run-time use; and 
dereferencing one of the numeric references by adding, to 
a virtual memory address, an integer offset contained 
within the one of the numeric references. 

27. A computer-readable medium bearing instructions for 
managing memory by a first process executing on a first 
processor for a run-time environment, said instructions 
arranged to cause one or more processors to perform the 
steps of: 

loading a plurality of objects into a contiguous memory 
segment of a virtual memory from a secondary storage 
that is not part of the virtual memory, wherein the 
objects stored in the secondary storage are loadable 
without unswizzling by a second process executing on 
a second processor that is incompatible with the first 
processor; 

loading references between the objects as numeric refer- 
ences from the secondary storage into the virtual 
memory; and 

dereferencing one of the numeric references by adding an 
integer offset contained within the one of the numeric 
references to a machine pointer holding an address of 
a beginning of the contiguous memory segment. 

28. A computer-readable medium bearing instructions for 
managing memory for a run-time environment, said instruc- 
tions arranged to cause one or more processors to perform 
the steps of: 

loading a plurality of objects into a plurality of non- 
contiguous pages; 
updating a page map containing a plurality of page 
pointers holding addresses of a beginning of corre- 
sponding said pages; 
loading references between the objects as numeric refer- 
ences from the secondary storage into the virtual 
memory; and 
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dereferencing one of the numeric references by: 

fetching a page pointer from the page map based on a 
page number contained within the one of the numeric 
references, and 
adding an offset contained within the one of the 5 
numeric references to the page pointer. 
29. A computer-readable medium bearing instructions for 
managing memory for a run-time environment, said instruc- 
tions arranged to cause one or more processors to perform 
the steps of: 10 
loading a plurality of objects into a virtual memory from 
a secondary storage that is not part of the virtual 
memory; 

loading references between the objects as numeric refer- i$ 
ences from the secondary storage into the virtual 
memory; 

converting base-offset numeric references into self- 
relative numeric references; and 

20 

dereferencing one of the numeric references by adding an 
offset contained within the one of the numeric refer- 
ences to a machine pointer holding an address of a 
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beginning of an object containing the one of the 

numeric references. 
30. A computer-readable medium bearing instructions for 
managing memory for a run-time environment, said instruc- 
tions arranged to cause one or more processors to perform 
the steps of: 

loading a plurality of objects into a virtual memory from 
a secondary storage that is not part of the virtual 
memory; 

loading the references between the objects as page -offset 
numeric references from a secondary storage; 

converting the page-offset numeric references into self- 
relative numeric references; 

storing the self-relative references in the virtual memory; 
and 

dereferencing one of the numeric references by adding, to 
a machine pointer, an offset contained within the one of 
the numeric references. 

* * * * + 
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